After an object which occupies an area to be accessed on a memory is produced and used, the object having been made unnecessary is erased as a general rule. An object once produced, however, can possibly remain without being erased to cause a memory leak for a reason that, e.g., a program writer has made an error in the control of allocating or releasing an area on the memory. If such a memory leak occurs, a usable memory area is limited. If memory leaks increase, the memory can possibly be exhausted possibly resulting in a problem of a system failure, etc.
In a system in which a garbage collection function (GC) is implemented such as the Java (registered trademark) language, an object and a pointer pointing at the object are not managed by the program writer but are managed by the GC. Thus, even if the program writer makes an error in the control of allocating or releasing an area on the memory, that kind of memory leak can be prevented. If no pointer points at the object, the GC identifies the object as garbage and a target to be erased.
In other words, the GC does not identify the object as a target to be erased while the pointer pointing at the object exists. Thus, under conditions in which the object and the pointer pointing at the object exist but nevertheless the object is never used again, the unnecessary object continues to remain in the memory. If such objects increase, the memory ends up being exhausted. That is a memory leak that occurs even to a system in which the GC is implemented.
While a program writer can use a lot of application programming interfaces (API) at present as open usage of software has become widespread, he or she finds it difficult to understand in detail the inside of an API that he or she will use. Thus, an error in a method for using the API can possibly cause a memory leak of a type such that a pointer of an unnecessary object exists and the unnecessary object resultantly continues to remain.
Some methods for detecting a memory leak, e.g., of the Java (registered trademark) language are known, such as Oracle JRockit Mission Control (Memory Leak Detector) or IBM HeapAnalyzer.
The method of Oracle JRockit Mission Control (Memory Leak Detector) is, if instances of one and the same class increase a lot in a time unit, for notifying a user of a name of the class and objects as a candidate of a memory leak.
Meanwhile, the method of IBM HeapAnalyzer is, if lots of instances of one and the same class remain on a memory at the end of the GC, provides a user with a name of the class and object information as a candidate of a memory leak.
These methods for detecting a memory leak have following problems in:
that the methods are unable to detect a small memory leak, e.g., just one leaking object;
that the methods are unable to detect a memory leak that occurred in the past. In case of an application that periodically repeats a memory leak, no leak can be detected even if a tool is used when no memory leak occurs; and
that lots of objects which remain on the memory do not necessarily cause a leak. An object programmed to be used at a certain time after being unused for a while can possibly exist. Thus, in order to identify whether a memory leak is present, it is necessary to observe information of the object for a certain period of time.
Further, a method for recording entire information of access to all objects on every page of a memory so as to detect a memory leak at a frequency of the access is known, e.g., as disclosed in Japanese Unexamined Patent Application Publication No. 2009-26081. Observation of the entire access to all the objects, however, excessively loads the system operation. Further, if objects of different access frequencies are arranged on a same page, the method for recording the access on every page reduces accuracy of the leak detection.